Télécharger

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
1
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
2
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
3
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
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
4
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
Questions/Réponses :
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
5
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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).
6
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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 :
7
EMERY Olivier & WILLM Geoffrey
IUT Lannion 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 ?)
8
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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é.
9
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
distinguished_name
default_bits
input_password
output_password
x509_extensions
= no
= certificate_authority
= 2048
= lannion
= lannion
= v3_ca /////////// A enlever sur le fichier server.cnf /////////////
[certificate_authority]
countryName
stateOrProvinceName
localityName
organizationName
emailAddress
commonName
= FR
= Bretagne
= Lannion
= IUT
= [email protected]
= "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)
10
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
distinguished_name
default_bits
input_password
output_password
[client]
countryName
stateOrProvinceName
localityName
organizationName
emailAddress
commonName
= no
= client
= 2048
= test
= test
= FR
= Bretagne
= Lannion
= IUT
= [email protected]
= 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
11
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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…
12
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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…
Questions/Réponses :
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é.
13
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
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
14
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS
- 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…
15
EMERY Olivier & WILLM Geoffrey
IUT Lannion RADIUS