TP – Un serveur RADIUS de laboratoire

BTS SIO SISR 2e année – Bloc 3 – S07 – en binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Installer un serveur FreeRADIUS, vérifier qu'il accepte et refuse correctement, lui faire attribuer un VLAN, puis comprendre par le test pourquoi un client doit vérifier le certificat du serveur.

Durée : 3 h 10. Prérequis : cours S07 lu.

Note

Un laboratoire sans borne Wi-Fi. Le serveur et ses « clients » tiennent dans une seule machine virtuelle Debian. L'outil radtest joue le rôle d'un authentificateur (borne ou switch) qui transmet un mot de passe ; l'outil eapol_test joue à la fois le demandeur et l'authentificateur pour une authentification PEAP complète. On teste ainsi le même serveur que celui d'une vraie borne.

Note

Comment ce TP fonctionne. Tu anticipes (« J'anticipe »), tu testes, tu notes ce que tu constates, puis tu expliques (« Je comprends »).

Binôme : ____________ / ____________

Contraintes

Une machine virtuelle Debian avec un compte sudo, instantané avant de commencer.
Paquets : freeradius, freeradius-utils (pour radtest) et un paquet qui fournit eapol_test (eapoltest, à vérifier selon la version de Debian de la salle).
Les identifiants (alice, bob, Lab-2026, le secret Secret-Borne-Lab) sont des identifiants de laboratoire : jamais repris ailleurs.
Tout reste dans la machine : le réseau de la salle n'est pas touché.

Partie A – Avant de manipuler (≈ 20 min)

J'anticipe. Réponds de tête, puis corrige avec le cours :

Question	Ma réponse
Qui, de la borne ou du serveur RADIUS, connaît le mot de passe d'un utilisateur ?
À quoi sert le secret partagé ? Entre qui et qui ?
Quelle réponse RADIUS ouvre la porte ?
Comment un serveur RADIUS place-t-il un utilisateur dans un VLAN ?

Éléments de réponse

Le serveur RADIUS ; la borne ne le voit jamais en clair. Le secret partagé protège les échanges entre chaque authentificateur et le serveur. Access-Accept. Par des attributs joints à la réponse : Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id.

Partie B – Installer et configurer (≈ 40 min)

B1 – Installation et arrêt du service

sudo apt update
sudo apt install -y freeradius freeradius-utils
sudo systemctl stop freeradius

Je comprends. On arrête le service pour le relancer au premier plan en mode « debug » : chaque requête s'affiche à l'écran, ce qui est la meilleure façon de comprendre (et de dépanner) un serveur RADIUS.

B2 – Déclarer l'authentificateur et son secret

Le fichier des clients RADIUS est /etc/freeradius/3.0/clients.conf. Un « client » est un authentificateur (borne, switch), pas un utilisateur. Le bloc client localhost représente l'authentificateur de cette machine. Modifie son secret :

sudo nano /etc/freeradius/3.0/clients.conf

Dans le bloc client localhost { … }, remplace la ligne secret = testing123 par :

secret = Secret-Borne-Lab

Je comprends. Le secret par défaut testing123 est connu de tous : le garder en production serait une faute. Un bon secret est long, aléatoire, et différent pour chaque authentificateur.

B3 – Déclarer les utilisateurs

Ajoute à la fin du fichier /etc/freeradius/3.0/users :

alice  Cleartext-Password := "Lab-2026"
       Tunnel-Type = VLAN,
       Tunnel-Medium-Type = IEEE-802,
       Tunnel-Private-Group-Id = "20"
bob    Cleartext-Password := "Lab-2026"

Je comprends. alice recevra, avec l'acceptation, l'ordre d'aller dans le VLAN 20 ; bob sera accepté sans VLAN. (Un fichier users avec des mots de passe en clair est un outil de laboratoire : en production, FreeRADIUS interroge l'annuaire.)

B4 – Lancer en mode debug

Dans un premier terminal, lance le serveur au premier plan et laisse-le tourner :

sudo freeradius -X

Il se termine par la ligne Ready to process requests. Si une erreur s'affiche avant (par exemple une écoute IPv6 qui échoue), note-la : ______________________

Point de contrôle : capture de la ligne Ready to process requests.

Partie C – Tester l'acceptation et le refus (≈ 45 min)

Dans un second terminal (le premier doit rester ouvert pour lire le journal du serveur).

C1 – Un utilisateur valide

J'anticipe. Qu'obtient-on en testant alice avec le bon mot de passe ? ______________________

radtest alice Lab-2026 127.0.0.1 0 Secret-Borne-Lab

(Les arguments sont : utilisateur, mot de passe, serveur, numéro de port de l'authentificateur, secret partagé.)

Éléments de réponse

Received Access-Accept, avec les trois attributs de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id = "20").

Je comprends. Relève dans le premier terminal la ligne qui annonce l'acceptation et les attributs envoyés : ______________________

C2 – Un mauvais mot de passe

radtest alice mauvais 127.0.0.1 0 Secret-Borne-Lab

Résultat : ______________________ Et dans le journal du serveur ? ______________________

C3 – Un utilisateur sans VLAN

radtest bob Lab-2026 127.0.0.1 0 Secret-Borne-Lab

Je comprends. Quelle différence avec alice dans la réponse ? Que ferait la borne de bob ? ______________________

C4 – Un mauvais secret partagé

J'anticipe. Que se passe-t-il si l'authentificateur utilise un autre secret que celui du serveur ? ______________________

timeout 20 radtest alice Lab-2026 127.0.0.1 0 testing123

Éléments de réponse

Aucune réponse : le serveur ne répond pas aux requêtes dont le secret ne correspond pas (la commande attend puis abandonne). Dans le journal du serveur, un message signale que la requête est rejetée à cause d'un secret incorrect ou d'un message invalide. C'est une protection : un appareil qui ne connaît pas le secret n'obtient même pas de refus.

Point de contrôle : captures de C1, C2 et C4.

Partie D – PEAP et le certificat du serveur (≈ 50 min)

D1 – Une authentification PEAP complète

eapol_test joue le rôle d'un client 802.1X. Crée le fichier de profil peap.conf :

network={
  ssid="LAB"
  key_mgmt=WPA-EAP
  eap=PEAP
  identity="alice"
  password="Lab-2026"
  phase2="auth=MSCHAPV2"
}

Lance le test :

eapol_test -c peap.conf -a 127.0.0.1 -p 1812 -s Secret-Borne-Lab

J'anticipe. Que doit afficher la dernière ligne ? ______________________

Éléments de réponse

SUCCESS. Dans le journal du serveur, on voit plusieurs Access-Challenge (les échanges du tunnel TLS et de MSCHAPv2) avant l'Access-Accept final.

D2 – Un mauvais mot de passe en PEAP

Remplace Lab-2026 par mauvais dans une copie peap-mauvais.conf et relance. Résultat : ______________________

D3 – Le client vérifie-t-il le serveur ?

Jusqu'ici, le profil ne contient aucune vérification du certificat du serveur : le client a accepté n'importe quel certificat. Ajoute dans une copie peap-ca.conf la ligne qui désigne l'autorité de confiance. Ici, le certificat du serveur est auto-signé (installé avec le paquet ssl-cert) : il sert de sa propre autorité.

  ca_cert="/etc/ssl/certs/ssl-cert-snakeoil.pem"

(à placer dans le bloc network={ … }). Relance : ______________________

Teste maintenant avec une autre autorité, qui n'est pas celle du serveur, dans une copie peap-ca-autre.conf :

  ca_cert="/etc/ssl/certs/ca-certificates.crt"

Résultat : ______________________

Éléments de réponse

Avec le bon certificat de confiance : SUCCESS. Avec une autre autorité : FAILURE — le client refuse le serveur, car son certificat n'est pas signé par une autorité de confiance. C'est exactement la protection contre une fausse borne : sans cette ligne dans le profil, le client aurait envoyé ses identifiants à n'importe qui.

Je comprends. Explique en trois lignes pourquoi la vérification du certificat du serveur est la mesure qui protège un client PEAP d'un jumeau maléfique : ______________________

Point de contrôle : captures des tests D1, D2 et D3 (les deux variantes).

Complément – Le côté switch : 802.1X sur un port filaire (≈ 25 min)

Dans la maquette précédente, radtest jouait l'authentificateur. Ici, c'est un vrai switch (simulé) qui bloque un port tant que l'utilisateur n'est pas authentifié, interroge un serveur RADIUS et place le poste dans le VLAN attribué.

Tip

Ce complément se fait dans le simulateur réseau. Télécharge TP-S07-8021x-radius.json, ouvre le simulateur avec Ouvrir, puis configure le switch SW1 : serveur RADIUS 192.168.20.5, secret de laboratoire Secret-Borne-Lab, aaa authentication dot1x, dot1x system-auth-control, port fa0/1 en mode accès avec authentication port-control auto et dot1x pae authenticator. Le compte de test est alice / Lab-2026, qui doit arriver dans le VLAN 20. Prouve-le avec show authentication sessions interface fa0/1. Vérifier mon travail contrôle chaque point. Mode d'emploi : Utiliser les TP du simulateur.

Réponds ensuite par écrit : que se passe-t-il si le serveur RADIUS est injoignable ? Quel VLAN donne ce switch à un poste qui échoue l'authentification, et pourquoi ne faut-il surtout pas l'envoyer vers le VLAN du personnel ?

Partie E – Concevoir le Wi-Fi de l'Atelier Verdier (≈ 25 min, réflexion)

Reprends le dossier de la séance S02 : un seul Wi-Fi partagé par le personnel et les invités, mot de passe inchangé depuis trois ans.

Question	Ma proposition
Quels réseaux Wi-Fi (noms, usage) crées-tu ?
Quelle méthode EAP (PEAP ou EAP-TLS) choisis-tu pour le personnel, et pourquoi ?
Dans quel VLAN et quelle zone (S05) arrivent le personnel, l'atelier (machines), les invités ?
Comment le profil des postes est-il imposé, avec quelle vérification du serveur ?
Que fais-tu des machines à commande numérique (qui ne savent pas faire du 802.1X) ?
Que se passe-t-il à l'arrivée et au départ d'un salarié ?
Un salarié veut utiliser son téléphone personnel : quelle option (invité, BYOD encadré, terminal fourni), quel VLAN, quelles mesures sur l'appareil ?

Nettoyage

Dans le premier terminal, arrête le serveur avec Ctrl+C. Pour remettre le service en l'état : sudo systemctl start freeradius (ou restaure l'instantané).

Retour en entreprise (si ta situation le permet)

Observer : le Wi-Fi de ton entreprise utilise-t-il une clé partagée ou 802.1X ? Qui connaît la clé ? Quand a-t-elle été changée ?
Documenter : compare le Wi-Fi de ton entreprise à ta proposition de la partie E.

Rendu

Compte rendu PDF, nommé RENDU-B3A2-S07-NOM.pdf, contenant les captures datées des parties B à D, les réponses aux questions et la proposition de la partie E.

Bilan de la séance

Compétence du référentiel	Ce que j'ai fait dans cette séance	Niveau
B3.3 – Sécuriser les équipements et les usages des utilisateurs
B3.5A – Assurer la cybersécurité d'une infrastructure réseau, d'un système, d'un service

Note

Je sais faire, sans aide :

Nommer les trois rôles de 802.1X et suivre le trajet d'une authentification ;
Déclarer un authentificateur et des utilisateurs dans un serveur RADIUS ;
Lire le journal en mode debug pour comprendre un refus ;
Faire attribuer un VLAN par RADIUS ;
Expliquer pourquoi le client doit vérifier le certificat du serveur.

Ce que je dois reprendre : ______________________