802.1x FREERADIUS - EMERY Olivierolivier-emery.fr/pdf/RADIUS.pdf · 1 EMERY Olivier & WILLM Geoffrey IUT Lannion RADIUS AUTHENTIFICATION 802.1x FREERADIUS Objectifs Configurer un

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


Déroulement du TP

En premier lieu on va réinitialiser notre routeur ainsi que notre switch Cisco

Sur le routeur : (deux possibilités)

Routeur# erase startup-config

Routeur# reload

Ou

Routeur# copy flash : vierge2800.cfg startup-config

Routeur# reload

Sur le switch

Switch# erase startup-config

Switch# delete vlan.dat

Switch# reload

Le switch servira de NAS (Network Address Server) appelé aussi authenticator. C’est un point d’accès

au réseau devant authentifier le client. Nous allons donc tout d’abord configurer deux vlans.

Création des vlans

Switch# conf t

Switch(config)# vlan 3

Switch(config)# name utilisateurs

Switch(config)# vlan 2

Switch(config)# name radius

Switch(config)# int vlan 2

Switch(config-vlan)# ip address 10.27.5.2 255.255.255.0

Switch(config-vlan)# exit

Activer sur les interfaces l’accès au vlan

Switch(config)# interface fasEthernet 0/1

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 2

Switch(config-if)# no shut

Switch(config)# interface fasEthernet 0/3-5

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 3

Switch(config-if)# no shut


Configuration l’authentification Radius

Activer AAA

Switch(config)# aaa new-model

Créer une methode d’authentification 802.1x

Switch(config)# aaa authentication dot1x default group radius

Autorisez l’authentification radius pour tous les services

Switch(config)# aaa authorization network default group radius

Activez l’authentification 802.1x sur le switch

Switch(config)# dot1x system-auth-control

Indiquez l’adresse du serveur Radius

Switch(config)# radius-server host 10.27.5.1 auth-port 1812 acct-port 1813 key lannion*

* Correspond à la clé de sécurité que l’on a définie

Si le switch nous informe que la méthode est dépréciée, configurer le spanning-tree en mode rapide

sur les ports

Switch(config-if)# spanning-tree portfast

Selon les modèles de switch, deux possibilités (a & b) de configuration pour active 802.1x sur les

ports du switch

Méthode a

Switch(config-if)# dot1x port-control auto

Méthode b

Switch(config-if)# authentication port-control auto

Switch(config-if)# dot1x pae authenticator


Questions/Réponses :

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


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

ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 ap_scan=0 network={ key_mgmt=IEEE8021X eap=md5 identity=”login_de_test” password=”votre_mot_de_passe” eapoli_flags=0 }

Pour lancer le supplicant sous notre machine Debian :

Wpa_supplicant –D wired –c /etc/wpa_supplicant/monradius.conf –i eth0


Lors d’une communication et d’une authentification, on voit un peu plus en détail ce qui s’est passé :

rad_recv: Access-Request packet from host 10.27.5.2 port 1645, id=1, length=142 User-Name = "test" Service-Type = Framed-User Framed-MTU = 1500 Called-Station-Id = "8C-B6-4F-98-EC-03" Calling-Station-Id = "00-19-B9-2F-5F-AF" EAP-Message = 0x020100090174657374 Message-Authenticator = 0xfaa39335cbf63a860274ec8c6bea105e NAS-Port-Type = Ethernet NAS-Port = 50003 NAS-Port-Id = "FastEthernet0/3" NAS-IP-Address = 10.27.5.2


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).


Du coté de notre client (Supplicant) :

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 :


Pour faire la petite histoire :

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é

serveur n’a été demandé ou paramétré.


Authentification par certificat EAP-TLS

Du côté du serveur Radius…

On va l’arrêter pendant la modification des paramètres

Ctrl+c

Mettre en commentaire cette ligne dans le fichier /etc/freeradius/eap.conf

Make_cert_command = ‘’${certdir}/bootstrap’’

Se placer dans le répertoire /etc/freeradius/certs et faire ces commandes

Make clean

Make destroycerts

Création des certificats serveur

Dans le répertoire /etc/freeradius, éditer les fichiers « ca.cnf » et « server.cnf ». Ajouter ou modifier

les sections suivantes :

[ req ]

prompt = no

distinguished_name = certificate_authority

default_bits = 2048

input_password = lannion

output_password = lannion

x509_extensions = v3_ca /////////// A enlever sur le fichier server.cnf /////////////

[certificate_authority]

countryName = FR

stateOrProvinceName = Bretagne

localityName = Lannion

organizationName = IUT

emailAddress = [email protected]

commonName = "TPRadius"

Lannion est le mot de passe d’entré et de sortie que l’on définit. Par défaut c’est whatever, s’il est

changé il faut éditer le fichier « eap.conf » et trouver la ligne suivante :

Private_key_password = whatever (←à remplacer par lannion)

mailto:[email protected]


Pour créer les certificats, une commande à faire dans le répertoire « certs »

Make all

Création d’un certificat pour un client

Dans le fichier « client.cnf » il faut modifier ces sections ou les ajouter

[ req ]

prompt = no

distinguished_name = client

default_bits = 2048

input_password = test

output_password = test

[client]

countryName = FR

stateOrProvinceName = Bretagne

localityName = Lannion

organizationName = IUT

emailAddress = [email protected]

commonName = test

Pour les créer, toujours dans le répertoire certs, faire cette commande

Make client

Déclarer l’utilisateur dans le fichier « users »

Test Auth-Type :=EAP

Mettre en commentaire le paramètre entré lors de la configuration du serveur en MD5

#Login_test Cleartext-Password:= « password »

On relance le démon freeradius

freeradius –X

mailto:[email protected]


Du côté Windows…

Les horloges des clients et du serveur doivent être à la même heure. Il faut aussi rapatrier les

certificats qui se trouvent dans /etc/freeradius/certs, ce sont les fichiers « ca » et « client ».

Ouvrir une commande console de management (MMC) puis faire menu → Ajouter un composant

enfichable → Ajouter → et enfin choisir CERTIFICATS

Sur le dossier « Autorités de certification racines de confiance » → clic droit → Toutes les tâches →

Importer le certificat « ca.der » puis le certificat « client.p12 ». Ils sont nommés par TPRadius pour le

premier et test pour le second.

On va maintenant paramétrer notre carte réseau → propriétés → Authentification → Carte à puce ou

autre certificat

Ensuite Paramètres → cocher comme l’image du dessous → chercher votre certificat dans le liste

« ca.der » nommé TPRadius…


Et enfin redémarrer la carte réseau…

Un pop-up s’ouvre (en général en bas à droite de l’écran), c’est le certificat qui attend une validation.

Nous sommes connectés…


Nous sommes devant une authentification sécurisée qui s’appuie sur les certificats électroniques.

Ainsi chaque partie (client et serveur) doit posséder un certificat pour prouver son identité.


Diagramme d’échange EAP-TLS

- Le client s’associe physiquement au point d’accès

- Le point d’accès envoie une requête d’authentification au client. Celui-ci lui répond avec son

identifiant (nom d’hôte ou login). Ce message est relayé par le NAS vers le serveur Radius

- Le serveur Radius initie le processus d’authentification TLS par le message TSL START

- Le client répond avec une réponse HELLO qui contient :

◙ des spécifications de chiffrement vides en attendant qu’elles soient négociées entre le client et le

serveur

◙ la version TLS client

◙ un nombre aléatoire (challenge)

◙ un identifiant de session

◙ les types d’algorithmes de chiffrement supportés par le client


- Le serveur renvoie une requête contenant un message SERVER_HELLO suivi :

◙ de son certificat (x509) et de sa clé publique

◙ de la demande du certificat du client

◙ d’un nombre aléatoire (challenge)

◙ d’un identifiant de session (en fonction de celui proposé par le client)

- Le client vérifie le certificat du serveur et répond avec son propre certificat et sa clé publique

- Le serveur et le client définissent une clé de chiffrement, et cela chacun de leur côté. Les messages

CHANGE_CIPHER_SPEC indique la prise en compte du changement de clé. TLS_FINISHED termine la

phase d’authentification (TLS_HANDSHAKE). La clé de session ne chiffre PAS les échanges.

- Si le client a pu vérifier l’identité du serveur avec le certificat et la clé publique, il renvoie une

réponse EAP sans donnée. Le serveur retourne une réponse EAP SUCCESS.

Cette méthode est configurée dans le fichier « eap.conf » (TLS – MD5 – TTLS – LEAP).

Le tunnel TLS créé lors de la création de la clé de session n’est donc pas exploité. Seul le TSL

HANDSHAKE est utilisé, il permet l’authentification mutuelle des deux parties. Bien que cette

méthode semble performante elle est compliquée à mettre en place (il faut bien gérer la gestion des

certificats) et assez longue. Imaginez que vous ayez un parc de plusieurs milliers de machines et

d’utilisateurs, cela ferait beaucoup de configuration. Il faut aussi que les horloges soient

synchronisées car dans la trame 802.1x Authentication il y a une partie « RANDOM » dans « Secure

Sockets Layer » qui détermine la date et l’heure, et cela des deux côtés pendant la phase Handshake

(authentification).

Conclusion

Il y a plusieurs méthodes d’authentification pour sécuriser une connexion et il n’est pas aisé d’en

choisir une. On utilisera facilement un serveur d’authentification pour sécuriser un réseau WIFI par

exemple avec la méthode EAP-TLS. Bien qu’elle soit plus lourde elle génère une clé WEP entre le

client et le serveur Radius (ici dans notre TP) qui favorise l’intégrité d’une communication. Attention

les données qui transiteront ne seront pas chiffrées !

Il se dessine pour nous une idée plus sécurisé et simple (relatif) d’utiliser des VPN par exemple…

Documents

802.1x FREERADIUS - EMERY Olivierolivier-emery.fr/pdf/RADIUS.pdf · 1 EMERY Olivier & WILLM Geoffrey IUT Lannion RADIUS AUTHENTIFICATION 802.1x FREERADIUS Objectifs Configurer un