Télécharger
Transcription
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